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BS Bearer Service 

CC Call Control 

CN ' Core Network 

GPRS General Packet Radio Service 

GSM - Global System for Mobile Communication 

IETF Internet Engineering Task Force 

• IP Internet Protocol 

ISBN ' Integrated Services Digital Network 

TFPC • IP Policy Control 

MO Mobile Originating Call 

MX .Mobile Terminal 

MTC .Mobile Terminated Call 

NS Network Service 

PDP Packet Data Protocol 

PDU • Protocol Data Unit 

PS Packet Switched 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RAB Radio Access Bearer 

RAN Radio Access Network 

RSVP Resource Reservation Protocol 

RT Real Time 

RTP Real Time Transport Protocol 

SAP Service Access Point 

SDU Service Data Unit 

SGSN Serving GPRS Support Node 
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SLA Service Level Agreement 

UDP User Datagram Protocol 

TE Terminal Equipment 

TSPEC Traffic Specification 

UE ' User Equipment 

UMTS Universal Mobile Telecommunication System 

UTRA UMTS Terrestrial Radio Access 
UTRAN UMTS Terrestrial Radio Access Network 
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BeBiJtiong 



Tfrcterant Applications: Applications on an external HoaL 

©ser Eqalpmont is a device allowing a user access to network services. For the 
purpose of 3GFP specifications the interface between the UE and the network is the 
radio interface. A User Equipment can be subdivided into o number of domains, the 
domains being separated by reference points. Currently defined domains are the 
USIM and ME Domains. The ME Domain can further be subdivided into several 
components showing the connectivity between multiple functional groups. These 
groups can be implemented in one or more hard wore devices. An example of such a 
connectivity is the TB - MT interface. 

The Radio Access Network domain consists of the physical entities, which, manage 
the resources of the radio cccess network, and provides the user with a mechanism to 
access the core network. The Access Network Domain comprises roughly the 
functions specific to ths-oceess technology. 
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Tim: IP Policy Arehltoefcur© 



1. Introduction 

This contribution proposes an IP Policy Architecture applicable to UMTS* 

2o Discussion 

During the S2 R00 Drafting Masting on QoS Issues which took place in 
Stockholm on May 9-1 1 , 2000,1 the following requirement was Identified following 
the discussion of AT&T© contribution entitled "Integration of SIP Signalling and 
Resource Management In 3QPP° (S2-000723): 

- tho need for enabling moctianlama to transfer local policy decisions resulting 
from events in the application level (e.g., local SIP proxy) down to the IP. 
bearer level (GGSN). j 

The requlramont suggests the) need for a suitable IP policy architecture which 
can Interwork with the application layer, formulate local policy decisions, and 
enforce policy in the IP beare( level at the GGSN. 

Recent developments In IET^ surrounding IP policy framework and protocols 
reflect industry thrust In providing sendees with appropriate quality of service to 
users who are willing to pay f0r better than best effort sen/ices. Some relevant 
IETF RFCs on the subject matter Include [RFC25731 "A Framework for Policy- 
based Admission Control", [HFC2748] The COPS Protocol 0 , [RFC2749] "COPS 
usage for RSVP n t etc. Several internet drafts are also being proposed which 
suggests possible extensions to the framework. 

It Is envisaged that the IP policy framework employed In UMTS would conform to 
IETF standards to leverage the expertise and developments in the mainstream 
IP community. ! 

On the other hand, there already exist working UMTS policy mechanisms within 
the UMTS specifications likejthe TS23.107. As R00 Is a smooth evolution from 
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R99 wherever possible, the UMtS policy mechanisms should continue to be 
used tor control of the UMTS be; irers. 



It Is Important to allow separate 
policy framework, since the UMtS 
distinct QoS management roles 
This means that backward, as 
functionalities should be ensure^, 
the two would occur only at wait 



ovolutlon for UMTS policy mechanisms and IP 
TS bearer sen/fees and IP bearer services have 
along pertinent segments In the end-to-end path, 
vtjetl as future compatibility for the respective 
L It la thus envisaged that Interaction between 
defined points to minimize Interdependence. 



The IP BS Manager within the 
enforcement point during the 
000732). Also, the translatton/rjiapping 
the networking between the 
UMTS and the external IP bearer 
Interaction between UMTS and 
thsQQSW. 



3. Proposal 

New te«t on UMTS and IP QoS 
element "IP Policy Control" Is. e I so 

The following additions/modifications 
Architecture Principles for Repass 



Informational nature, additions 
rotated protocol Interfaces, ore 



GSN has been Identified as being a policy 
" drafting meeting In Stockholm (endorsed S2- 
functlon within the GGSN must provide 
mechanisms and parameters used within the 
service (23*821 Section 9.2). Thus, the 
IP policy mechanisms should effectively occur in 



Policy Requirements Is proposed. A new 
Introduced in the ROO QoS model. 

are proposed for Chapter 9 of TR23.821 
2000. 



As Figure 9-1 of TR23.821 (a modification of Figure 2 in TS23.107) Is of 



to the figure; i.e., IP Policy Control element and 
attempted to help solve the QoS policy related 
concerns that havo been Identified so far. After a better understanding of 
requirements and subsequent agreement on appropriate solution within the QoS 
drafting group, it Is to be determined what and how aspects of the proposal can 
be Included In the normative portion of the ROO standard. 



Note: The proposed changes ere 
approved (endorsed by tho QoS 
Manager Capabilities) and Tdoc 



ai town against TR23.821 VO.2.0 Incorporating the already 
drt fting meeting In Stockholm) texts In Tdoc. S2-O0Q732 (IP BS 
Si '•000735 (QoS Control of the IP Bearer Service). 
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9 QoS 



[Note: The following sectiono are intended to be included In TS23.1Q7 (proposed chapter, if any): 

- 9.1.1 (new Chapter 4,4) j 

- 9.1.2 fnaw Chanter 4^ \ 

- 93, (Chapter 6\3) 

9.1 Requirements 

9.1.1 End-to-Bnd QoS Negotialiojn Requirements 
(no Change) 

9.1.2 Q&Eslijcy fifiq^^eq\a j 

° Tho erfotf nn UMTS noHcv reochoninrBn ahull ceatinoe to bo unod fair contort of tho UMTS 

hanrora: Jt in reconniaed that there already exintn UMTS noHcv mechaniama within tha agisting UMTS 

I 

o ThfrKP noUcy gro rowYO gfe qftBffhwj In ^BCTRjTfrgtol^ conforei to HETTP "Internet 

Stnnflni&f: Tha B3TF policy ftnmqworkjhall ha medibr policy decision, authorization, and control 
of the IP level functionality, at both User and network level. Thin anaurea-confbnnanca to mainstream 

o Trtmra shnfl bo smronmrloB rkritpocmf tho neono ond reign off tha UMTS poll cv mcchnnlmnn mad tho 
EPnoUcv frnroareorh; This ia to facilitate separate evolution of these functions. Interaction between . 

WMXS tottm flflTYifffin nnrt pe^ services flnlv flficwr bi waII rtnfirmd ppintoi thna firoronfUhn 



9.2 QoS End-to-End Functional Architecture 

To provide QoS end-to-end, it is necesoijry to manege the QoS within each domain. An IP BS Manager ia 
used to control the esterna] IP bearer navvies. Due to the different techniques used within the IP network, 
thio conununicatea to the UMTS BS manager through the Tranalodon function. 

To enable coordination botwaen aventn in the Application layer and resource mannnemftnt in the IP nearer 
layer, nn element called IP Policy ControUn nnedjvn a Inwteal policy_deciniQn element ttaftt in lowd to the, 
network providum reaourcen for the beapr nattu with protocol inteTfacen to local ajroljcflttfln 
fHgverafaroirieg. aa well nn to the QOSNI wfagre policy dBclstann are enforced. 

The TP polic y structure bases policy decisions only on information obtained from nodes / elements within 
tha network which ownn the resources for the hearer path, i.e.. the local network. 



In, addition. It la ponflible to implement 



policy decision element internal to the IP BS.MannRCT in the 



GGSN. The I P policy architecture docn not mnndate the policy decision point to be external to the QGSW. 



Whenever resources not owned or 
necessary to intcrwork with an externa 

IP BS Mnnngor 



by the UMTS network are required to provide QoS, it is 
resource manager that controlo those resources. 



controlled 
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Ito p BS Manager uses standard IP mcchsnlomu to manage the IP bearer service. These mechanisms may 
be different from mechanisms used within t&e UMTS, and may have different parameters controlling the 
service. The translation/mopping function provides the interworldnB between the mechanlsma and 
parameters used within the UMTS end the external IP bearer cervice, and interacts with the IP BS Manager. 

If an IP BS Manager exists both in the UE And the Gateway node, it ia possible that these IP BS Managers 
communicate directly with each other by ospng relevant signalling protocols. 

i 

The required options in the table define thej minimum functionality mot shall be supported by the equipment 
In order to allow multiple network oporototp to provide Intsrworldng between their networks for end-to-end 
QoS. Uae of the optional functions listed b^low, other mechanUmia which are not listed (eg over- 
provisioning), or combinations of these mflfrhnninmn ore not precluded from use between operators. 

The IP BS Managers in the TJB and GGSN] provide the following set of capabilities for the IP bearer level: 



Optional 
Optional 
Optional 



Required 
Optional 
Required C) 



Provision of the IP BS Manager Is option il in the UE, and required in the GGSN 



operator choice. 



enforcement lo required within the GGSN, the control of IP policy 
Whore the APN is not located at the GGSN. the location of 
urteotifjuticm. 



(°) Although the capability of IP policy 
through the GGSN ia o network 
policy enforcement point is for further 

XPPoMcv Control 

The IP Policy, Control to a logical local etallcv decinion element which uses standard IP mechanisms to 



Implfflmfflrt BftlilfrY In rt rc HE te ffarjRW.. mm mfflhwilftmnmRv fro, finnfmmwt to. for mmnmio. the 

framework defined in IETF fBPC23731 f A Framework for Policy-baaed Admiiwion Control" where the TP 
Policy Control in effectively n Policy ttefcialon Point (PDP^ The IP Policy Control makes decisions In 
regard to network based IP local policy jmnn oolicv ru!ca» and communicates these decisions to the IP BS 
Manager in the GGSN. which la the IP I olicv Enforcement Point ( PEP*. 



A protocol interface between tha IP Polfev Control and local application servers/proaiea f e.g. local SIP 
ptoxv> support the transfer of policy routed information from the application layer, to tiw policy, derfa ion 

nointi f frtifft rial mt*i.7te fflwgr mGhffkm* nmfuwk vfathtT pmrntm °r jmr'ffartffzflff* ff»4 /iff* 

A protocol interface between the IP Polfcv Control and GGSN support tha transfer of informatlmi and local 



77m ffmfff nKrcfrmfrrm. ffrpwegfa whfitf 

farthar study. Ona aoMtbtiLCandldatn i 


Qt nmrktm or mnfa rrffcgrf, nnrf hovt th<rt are ff jffftflnt for 
i 'for fflfi? ftrfffpcflt [RFGZ7*#l wfticA Amrilrn a ximpk mm 


flwrf nMffonjff ff rp(ffffff< that «w fa mrrt 


fff fwwrfwifift ffgtfffY information frffftrrmn ff ffffffov mr <PftP) nrtf 




j tha shnalllns protocol in thn IP bearnt InveLa COPS nroiseoi 


variant carrvinx zmhadded RSVP isfai 


matian. la.. COPS-RSVP. dnfined in (RFC27491 mavJfa tutlL) 




»Hcv Control mav hava protocol Interfaces to Qthar dsvicQsJAJL. 


feftffiMrff/i ftrgferr) whfch mm 


I tranjfar of information fa.n„ authentication, availability of 


rmmM* tmr. ) fer m fa tow/ /m/fey 




(Editorial note: Whara th« accasxjnii 


( f of fo* APN h not located at tha GGSN. tha loeattarutt policy 


trnfammfint point k for fhrthnr inmi 


nation. Th« IP palicv architecture far cas<u.whara th&jiCESS^oeinl 
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QfthiAPN to faffqfffrf fri a third Portv n<mvorfe fcg.. a corporate network h for farther imrfv. > 
Resource Manner 

Within Uw UMTS network, there is reaource management performed by various nodeo in the admission 
control decision. The reaourcea considered here are under the direct control of the UMTS network. 

In IP Networks, It in also necessary to ucipjiu i resource management to ensure that resources required for a 
service are available. Where the resources for the IP Bearer Service to be managed are not owned by the 
UMTS network, the resource management of those resourccQ would be performed through an external 
resource management function for the IP network. 

In addition, where the UMTS network lo also using external IP network resources as part of the UMTS 
bearer service (for example for the backbone bearer service), it may also be necessary to Interwork with an 
external IP resource manager. 

Figure 9-1 shows the scenario for control of an IP service using IP BS Managers in both possible locations 
in tho UB and Oateway node and an external Resource Manager. The figure also indicates the optional 
communication path between the IP BS Managers inthcUE and the Gateway node. 




Figure 0-1: QoS managomarrt funetiono for UMTS boaror oorvleo In tho control piano for an 

ontomal IP Sorvtco 

Note; This does not cover the cases of aclrcuit switched service, or an TP service interworking with an 
ATM service at the gateway node. 

Editorial note: The actual split of the UB into separate elements (as described in TS 23.002 and TS 24.002) 
as well as the terminology regarding the UB elements and the distribution of functionalities between the UE 
elements is for further study. The modeling of tho UE in TS 23.107 lo not in line with TS 23.002 and TS 
24.002, which makes this clarification necessary. 
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Editorial aotoi Tha a dditioa of poli cy fita o tiowalit y to th» Qo R fhu w woik d cw rib a d hte U foi furthf 
■ mdy i Th o l aa atiow of l h > polic y Minted ftuiodoHaHri aa ia fo » fimhw a tnd y aa wlli 

Kittrtol npfr; ElSTrrcnPLsatcTiiM fa tiitmrici wftd w hirtUgtu w4 wplnto wiibh nhrtom to 
rearircnwfM ftathavg ton ttcntifiri within tfw Qft3 drafting grew. If clement w interfmw are apreifM 
or nttnd*M within 2QPP. tim ahftll to inslrted in the Rgfrreiwo ArehUwtorc. 
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Title: 



Application of IP Policy Architecture in UMTS 



1 INTRODUCnON 

Thto contribution considers the reqiniemsnts as outlined in contribution S2-000723 and subsequent discussion. ancVexamines how 
those requirernento could be met fay application of policy control wring the architecture proposed irr contribution S2-000840. 

2 B3ESCKEF3HON 

2.1 ReqimJremeHilfcs : 

The requirements derived from contribution S2-000723 and subsequent discussions are Identified below. Note that the derived, 
requirements aa elated here have no statao and ere not recognised oa formal requirements within 30J*P. Furthermore, the 
requirement listed below are not assumed to be a definitive or complete set of requirements for- the problem space Identified in that 
contribution. : 

Additional discussion is recommended to increase the understanding of the specific requirements, which could enable an even 
broader range of solutions. In some coses, the requirements stated have been logically extended to .cover additional functions, 
and/or possible alternate options have been proposed. Hence, this contribution is aimed to invite further discussion of both the 
proposed solution and the requiremento. In the discussion below, the requirements ere described in relation to a telephony call being 
placed over an IP based telephony network. However, the requirements for the controls are equally applicable for multimedia 
service, and fox other types of applications entirely. 

I. Restriction on establishment of UMTS bearers 

The requirement stated was that the conversational bearer may only be permitted for use with the AT&T telephony network 
This requirement could logically be extended to have control over different typeo of bearer, dependent on the either the 
network they are connecting to (I.e. the AFN), or the application that they are they are working towards. Although the former 
function may be useful, It is assumed that the latter case Is the requirement The requirement is logically extended to allow 
restriction of the bearer types to be controlled from any application. 

Theft of Service; 

There were several requirements that were raised under the banner of "theft of service". These are discussed individually. 

Z Aeceao to resources within the telephony network is restricted by gating applied from the application level (i.e. on application 
server such as a SIP proxy can restrict access to the service network resources). The gating shall enforce that communication 
across the telephony network is only according to the connections approved from the application server. 

3. The telephony service based charging for data transfer (active phase of call) Is not started until some time after the access 
bearer resources are reserved. The user cannot use these bearer resources without charge. The original stated requirement was 
that the user waa not permitted to utilise access network resourcei prior to the start of charging. A proposed alternatives is: 

- The user shall be permitted to utilise access. network (e.g. UMTS) resources prior to the start of call charging, but that a 
charging rate specific for the access bearer would be applied for unauthorised data flow prior to the active phase. 

- Alternatively, the access bearer may be closed down if it io used fraudulently and no access network charging is applied. 
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- In addition, resources that ere not authorised and charged appropriately should not ba permitted to be reserved. 

Note that the solution overview below describes the flow of information between nodes to allow the policy decisions to be made in 
this way far tbia application. However, this contribution does not propose that the application is designed in this way, or that IP 
policy control should ba used in the manner Indicated. Rather, this contribution is simply giving an example of how policy control 
may be utilised within thin architecture. 

However, alternative solutions may be used where various policy decisions are not outsourced to the IP Policy Control, but are 
made locally within the node. This contribution does not propose whether or not these decisions should ba outsourced; it merely 
shows what is involved If they are outsourced. 

2.2 Sdtotloia OveirvSew 

An overview of how the requirements can be met using "policy" mechanisms is discussed. Further detailed analysis can be 
performed when the requirarnentfl are clarified. The architecture for IP policy control specified in contribution S2-000840 is 
applied. This architecture to shown In me figure below. 
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figure 1 Basic Architecture 

An information flow is described below, which is depicted in figure 2. 

The end hosts initiate the application, in this case atelephony call, using SIP signalling (1). Tho SIP signalling passes through a SIP 
proxy server within the network. The SIP session identifies the end points within the telephony network, denoted by their IP 
addresses. These TP addresses both reside within the addressing space of the telephony network (if the call does not terminate 
within this telephony network, the addresses are the gateway address within tho telephony network which the bearer passes 
through). 

d to establish the QoS enabled access bearer for the data plane. This may occur 
-conditions for the session, Tho UE must select the access bearer type to be used 
caWrsational bearer, and it initiates a PDP context for the bearer level. 



Insdd 



After the session has been started, the UE will 
during the session establishment as part of the preconditions 
based on the required characteristics, such as a 



r 
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The UE then requests establishment of the UMTS bearer (3). The tramlation/mappins function in the OGSN maps the UMTS 
bearer service into a detailed description of an IP service that to being provided to be uoer over the access network. The IP BS 
Manager contacts the IP Policy Control to determine whether this access TP bearer service in permitted to be established (4). The IP 
Policy Control may apply rules that restrict the use of specific access bearers dependent on network factors such as Involvement of 
the Local SIP Proxy Server. Since the IP Policy Contro\ hoa been informed that the Local SIP Proxy Server is in use for this 
connection, the tue of this bearer type is approved* 

Authority to establish the access beam is separate from authority to transmit data into the telephony network. When the bearer is 
established, a "gate" is established at the OGSN that controls what data is permitted to enter the telephony network (6). This gate ts 
similar to the DS edge functionality, performing classification and policing of the data. The gate is controlled by data received from 
the application through me IF Policy Control. 

i 

Prior to the session reaching the active phase, the UE may send data regarding the proposed usage of the access bearer to the 
GGSN. This information may be sent to the GGSN either through IP level signalling such as RSVP, or it could alternatively occur 
through PDP context signalling, as proposed In contribution S2-000B42 for the uplink direction. For the downlink direction, the 
FDP content signalling already mchides information about the TFT filters. In the figure below, the proposed bearer usage 
information is panned through PDP context signalling, i 

When the OGSN receives information about the traffic* usage tor this bearer, the IP BS Manager may authorise the usage of the 
bearer (5). If the proposed usage does not agree with that .authorised by the SIP proxy server, the GGSN may reject the bearer 
establishment, or the cession establishment In the casejof RSVP. The SEP proxy server by this time must have supplied information 
to the IP Policy Control regarding the authorised traffib descriptor. 

When the session reaches the appropriate state (Le. thf active phase), the gate Is opened to allow the data ficom the user to enter the 
network (7). j 

When tho session is finished, tha SIP proxy server revokes authorisation for both the session and the bearer level. It shall also close 
the "gate" that has been opened from the GGSN towards the telephony network. This action occurs at several different levels. The 
SIP proxy server tarminateo the session directly to the UE. It sends information to the policy server which results In me closing die 
gato at the GGSN. Finally, the SIP proxy server sends Information to the policy server that results in the termination of the bearer, if 
the bearer termination has not already been hririated ^om the UB. 

The figure below shows o simple overview of the information flow between the network elements. The actual protocols and 
messages that would be used within thia flow are for unhcr study. 
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Inf ormmtio© Flow 



Some additional comments can be mad© to the propoj al described above. 



1 requiri d 



An aim with thin proposal io that the functiono 
applications. Therefore, the interface from the GGSN 
these functions. It io for further study what this 



proto* ol 



The IP Policy Control may receive information from different 
are applying control to within the GGSN may be the 
information is used may be different for different apj 
Control and the applications* although it is recommepded 



application!) that want to apply control. Although the function they 
lame, the actual information supplied by the application and how that 
I Ueariono. Therefore, there may be a range of protocols between the IP Policy 
that applications with similar policy controls use the same protocol. 



Requirement 1 specifies that the use of specific 
application (In this example the telephony call) deteibrrinea 
SIP proxy trmtisr^ermitted to perform this eumoxi&a ion 
communicatee to the IP Policy Control that the Lees 1 



For scenarios where the UMTS bearer io being 
network), the normal UMTS policy mschaniamo maV 



Requirement 3 states that resources that ore not 
control Information from the SIP proxy 
session is in an appropriate state to authorise the 
Control, the IP Policy Control makes a decision on 
has approved the connection to be made at this tinw , 



through connection (< g 200 OK et answer in g f ^ 



Session through connec tion nnthorised 



at the GGSN are not application specific, and may bo required for different 
to the IP Policy Control should be & standardised interface far control of 
interface should be. 



bearero will be restricted dependent on not just the application, but that the 
whether the bearer type is authorised for use. To enable this control, a 
(this must be a trusted node within the network with this responsibility) 
SIP Prosy Server is involved in the call for this UE. 



efltaVli&hed 



to other networks (I.e. where the APN is not accessed from the serving 
be used to apply control over establishment of the UMTS bearer services. 



authorised and charged appropriately should not be allowed to be reserved. Tho 
server desif nates not only that the call is using the Local SIP Proxy Server, but also that the 
be urer service. When the IP BS Manager in the GGSN contacts the IP Policy 
lot just whether the UE is authorised for the bearer type, but that the application 
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A possible alternative to thin mechanism is to allow the bearer service to be established independent of the session otate. In this ease 
though, the charge applied for the access bearer would be different dependent on the current session state. If the session exists, there 
may be no access bearer charge, but if it doesnt exist, thfero may be access bearer charges even if any dam sent on the bearer is 
subsequently discarded. | 

Requirement 2 specifies strict control the destination for data that is allowed to enter the telephony network. Thin may be because 
the telephony service could have destination dependent charging, and also because it may be performing resource reservation for 
the connection. In order to provide this control, the "gating" function in the GGSN must receive configuration data from the SIP 
proxy server via the IP Policy Control. 

If the UB doea not provide signal proposed uoago infoxWtion for the connection, the network can only verity correct usage of the 
oervice network by checking the received data against the gate, and it cannot perform any additional resource management checks. * 
Reception of traffic profile information allows the UB to verify its* intended usage is authorised, and permits additional negotiation • 
of IP level resources. 

There are different actions within the policy enfercetnant that may be applied by the IP BS Manager. For example, if data is 
received that is not allowed through the gate, the IP BS Manager may take actiono from discarding the data to terminating the 
~* bearer. The scope of policy enforcement options must be determined and considered when selecting the protocol to be used 
between the TP BS Manager and the IP Policy Control for each policy function. . 



3 CONCLUSION ! 

Within this overview, the following requirements havjbeen considered: 

1. Authorisation of UMTS bearers from me application. 

2. Control of opening and closing the gate for data to enter the service network, controlled from the application server through the 
policy server. ; 

3. Control of the level and destination of data parmljted to pass the gate and enter the service network, controlled from the 
application server through the policy server. 

It has been demonstrated that the TP Policy arcMtectuje proposed In S2-O00841 can be used to perform policy control in a manner 
enabling these requirements to be fulfilled. Therefore^ it is proposed that contribution S2-Q00841 is accepted. 
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Title: End-to-end QoS Relaftjd Information Carried in the PDP Context Message 



1 ' INTRODUCTKON I 

hi order to provide end-to-end QoS, resources need to be managed both in the UMTS network and in the external IP 
network. This contribution examines how the PDP context can be used to provide information that is necessary to 
' control end-to-end QoS. The oolution discussed In this document is applicable e.g. in the situation where the UB does 
not provide an IP BS Manager. Note that this scenario was described In S2-000813. 

2 discussion ; 



2.1 Ead-to-emd QoS Related ReqiiliremeHita 



The end-to-end QoS negotiation requirements listed in Section 9.1 of TR 23.821 include the following two 
requirements: 

o Tha UMTS QoS negotiation mechanisms used for providing ond-to-and QoS shall not make any assumptions about 
application layer signaling protocols. 

o The UMTS network shall be abh to negotiate end-to-and QoS also for mobile terminals and applications that are 
^ not able to usa QoS negotiation mechanises othar than tha ones provided by UMTS. 

End-to-end QoS provisioning implies that resources in the external IP network need to be managed by the IP BS 
Manager in the OGSN. There are different IP resource management techniques available for the IP BS Manager to 
^.manage the IP resources* and some of these imply call admission control (CAC) functionality in the QOSN. hi order 
~ for the GCSN to exercise CAC, information ajbout the IP traffic (e.g. average and peak rates, required QoS and 
destination) may be necessary. 

The first requirement above implies that the initiating terminal cannot rely on application level signaling to check 
whether resources are available through the njetwork and at the remote access. It follows that such a resource check 
must be performed at the bearer level. If the pB does not perform this bearer level request, then the QGSN may need 
to perform this function, and requires information about the destination IP address in order to perform a CAC decision. 

The second requirement listed above implies) that end-to-end QoS must be provided even for terminals that do not 
implement the IP BS Manager functionality and only use UMTS BS Manager (e.g. PDP context signaling) to request 
resources within the UMTS network. 



From these requirements and the 
information to the OGSN. We propose that 



discussion [above it follows that the UB may need to signal end-to-end QoS related 
i his piece of information be added as a new information attribute to the 
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existing PDP context This end-to-end QoS attribute shall be transparent to the UMTS network and may be 
piggybacked within the existing PDP context sigru ling. 
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2J2 Possible Extensions tofclhePBP Context 
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diagram of tho aomimed network model 



The appropriate extension of the PDP context 
OGSN. Depending on the scope of the CAC in 



di pends on the IP BS functionality that is actually implemented in the 
the GGSN, we distinguish tho following two cases: 



Case 1: CAC is based on th e availability of resources over which the QGSN hag control 



In this case the necessary QoS information 
Function between the UMTS BS Manager and 
allow for policy decisions based on RSVP 
" specific to the IP bearer. For instance, ouch 
descriptors. Such descriptors may be based on 
differentiated services or integrated services, 
generic IP bearers. 



maybe 



extracted from the existing PDP context by the Translation 
i he IP BS Manager. In order to facilitate efficient TP resource usage and 
the PDP context could carry additional QoS related Information 
additional parameter can specify traffic descriptors and QoS 
the ones associated with standard IP mechanisms, such as the 
Alternatively, these descriptors may be based an the concept of the 



parafneters, X 



Cm 3; Thfi CAC to frititionaHv towed on the mwm sitofttism the Egress. SkA 



In this case the destination IP address needs to 



The exact form of this additional QoS attribute 
attribute include: 

- parameters associated with the 

- parameters associated with the integrated 

- generic IP bearer parameters 



be carried in the PDP context (apart from the descriptors of Case I), 



in the PDP context is for further study. Candidates for the basis of this 



differentiated services framework 
tervices framework 
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In order to allocate IP resources in an 
optional attribute "End-to-end QoS". The conten 1 
transparent to the UMTS BS Manager, but allow* 



3 PROPOSAL 

It is proposed that 3GPP S2 consider the argument s raised to extend the PDP context with an additional attribute 
having end-to-end QoS significance. 

We propose the following text to be added to Section 9 of TR 23.821 
9jc IP Level End-to-and QoS Attributes 

(Editor's note: The contents of this section Is intended to be included In a new subsection 6.4.y ofTR 23 J 07) 

external m itwork and 



to execute CAC the PDP context may contain the 
of this optional attribute is for further xtudy. This attribute is 
the transport of IP QoS related information. 



It is also proposed that a new subsection be added to Section 6.4 of the document TR. 23.107 M QoS Concept and 
Architecture": 

&4.y IP Level End-to-end QoS Attributes 

[t] TR 23.821 "Technical Specification Group S arvices and System Aspects; Architectural Principles for Release 
2000" 

[2] TSG-S2 S2-O0OS13, "QoS Conceptual Models 1 

[31 TR 23407 "Technical Specification Group £ ervices and System Aspects; QoS Concept and Architecture, Release 
1999" 
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